COMMENT ⊗   VALID 00009 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	See all RLL.BBD[rdg,dbl], 
C00003 00003	∂TO SKLEIN@ISIB 13:25 8-Jan-82
C00009 00004	∂11-Jan-82  1748	Steve Klein <SKLEIN at USC-ISIB> 	Re: Some comments    
C00019 00005	∂26-Jan-82  2013	Steve Klein <SKLEIN at USC-ISIB> 	awoof 
C00020 00006	∂08-Feb-82  1617	Steve Klein <SKLEIN at USC-ISIB> 	grmmph
C00021 00007	∂TO sklein@isib 15:51 9-Feb-82
C00031 00008	∂16-Feb-82  1415	Steve Klein <SKLEIN at USC-ISIB> 	postponement    
C00032 00009	∂TO skein@isib 18:01 17-Feb-82
C00033 ENDMK
C⊗;
See all RLL.BBD[rdg,dbl], 
also ARCHIVE.RLL[rdg,dbl] for backed-up information
(USERS.OLD had bunch of users,
 SKLEIN.2 have old messages with Steve)
∂TO SKLEIN@ISIB 13:25 8-Jan-82
Some comments
Steve

(1)	I realized this morning that the defn of *vaLue* is wrong.
The HighLevelDefn says to apply the MyLivesInSlot slot to the 
value of (GetValue un 'MyLivesInUnit).
That's close: it should, however, apply the function stored on un:MyLivesInSlot 
to that un:MyLivesInUnit value.  As there is currently no direct mechanism for
doing that, we could define a function  GetFromPointer,
which takes a unit, un, and returns (essentially)
	(APPLY* (GetValue un 'MyLivesInSlot) (APPLY* (GetValue un 'MyLivesInUnit)))

The GetFromPointer unit would include some useful facts -- it rangetype should be
something like
	(FSingleton (UnrestrictedType (*FromDomain GFP-Fn)))
where GFP-Fn would take a unit and return something like 
'(*FromDomain *vaLue*Fn).  [Or something like that -- see MapCross-Fn, or whatever.]

The idea is for *vaLue*:RangeType to be
	(FSingleton (UnrestrictedType (*FromDomain *vaLue*Fn)))
where *vaLue*Fn takes a unit and returns the rangetype of the MyLivesInSlot of
that unit.

(2) Doug needs a brief, 1 page description of what's going on there - for some
report or other.  It doesn't have to be prose, just enough for him to understand
what sort of things youse guys are doing, and why you are using RLL.

It might be interesting to see, in addition, your agenda of things needed,
and fixes made.  (Basically for my edification...)

(3) Just a reminder: ComplexVV now calls (GetValue ? 'VerifyElement ...);
but should be calling a GetField - as the VerifyAll thing does.

(4) At some point I should send over the macro stuff I have up and running here;
and the next batch of LISP files.  From there you could have the most updated
version.
(Until Rand and/or thesis stuff forces me back to hachery.)

(5) Some thoughts on EqualFormatSpec:
It would be a list, with each member of the form:  (<format> <function>).
[That is, EqualFormatSpec:RangeType = 
    (FSet (FListN (UnitType (*P AnyFormat))
		  (FunctionType (*Range (FListN UnrestrictedType))))).]
If (fmt2 fn2) was included on fmt1:EqualFormatSpec, then
if some value, val, was acceptable to fmt2, then (fn2 val) will qualify as
an instance of fmt1.  For example, FSet:EqualFormatSpec ==
      (	(FOrderedSet	IDENTITY)	; Any ordered set is already a set
	(FList		MKSET)		; this removed duplicated elements
	(FBag		MKSET)		; (removes duplicated elements)
	(FListN		Scream)		; could be MKSET, but this is safer
	(FSingleton	LIST)	)	; ie this list qualifies*

*: actually the function FakeList should be used, where
(FakeList (v) (COND ((EQ v NoEntry) NoEntries) ((MustComputep v) v) (T (LIST v)))).

Given this, UnionDT and IntersectDT may be easier to (re)write, as well as
SubSpecFn for formats.  Note it puts the facts (closer to) where they belong 
-- on FSet, etc., rather than within a few functions.

Two final notes:
(i) Finding (fmt2 fn2) included on fmt1:EqualFormatSpec restricts the
fn1 in the (fmt1 fn1) included on fmt2:EqualFormatSpec.  [Note it does not
completely define that fn1.]
(ii) Eventually it would be nice if EqualFormatSpec could be generated from
"first principles" -- looking on the various format's FormatCharacter.

----
That's all for now.  Let me know how your work load dwindles, and whether/how
this RLL marrass(sp) works.  I meandered over to ISIB last night, and found
the stuff we did unsaved! (or at least I couldn't find it).  

Hope things are going ok,
	Russ

∂11-Jan-82  1748	Steve Klein <SKLEIN at USC-ISIB> 	Re: Some comments    
To: RDG at SU-AI

I'll look over the first 90% of your mss. later, but you are right on the last
point.  I was on my way to the Consumer Electronics Show in Las Vegas just 
after talking to you and managed to logout without saving the RLL image we
were working in.  Good thing that the dribble file (presumably) still exists.
Murphy's law strikes again...
-------

∂13-Jan-82  1724	Steve Klein <SKLEIN at USC-ISIB> 	stufflets  
To: RDG at SU-AI

Accumulation of small things:

∂TO sklein@isib 20:28 13-Jan-82
Possible answers
**** My comments are interspersed.  enjoy...

1.  for Range restrictions, the original solution you wrote up talks of
  checking u:MyLivesInUnit 's SuperTypEx's for superspecs.  However,
  this only works for CLASS restrictions.  If the RangeType spec is found
  on a subunit for an INSTANCE, then it has no TypicalExampleOf slot and
  hence no SuperTypEx's.  
**** Q: Have you a scenario in which this occurs?  As you noted, the only
	place where a restriction currently makes sense is for classes --
	basically because I didn't see any other place where a restriction
	might occur...
  HOWEVER, the concept seems still valid, since
  it has some superior TypicalExamples.  What do you think of changing
  the defn of SuperTypEx (and rest of group) from 
     (Composition TypicalExample SuperClass TypicalExampleOf) to
     (Composition TypicalExample SuperClass Isa) ?
**** Hmmm - Independent of the first point above, this might still
	be a good idea. (Given that TypicalExampleOf is (essentially) a subslot 
	of Isa (I think).  The question again is, is this needed?  This will
	make the computation of SuperTypEx (potentially) more expensive, if one
	day we formally make Isa a complex slot.  When will you want a SuperTypEx
	of a non-typicalexample?  (Beyond that possible case of restricting
	from an instance.)

2.  I'm tentatively calling the slot you named SuperSpecFn 
   FnForVerifyingRangeRestriction (unless you have an objection).
**** Sure - it's you who'll have to type that Moby-name.
	But I think it does convey the correct idea.

3.  Following convention, the fn on RangeTypeOfTypicalSubUnit:VerifyAll
   seems to look like (LAMBDA (un sl val ...].  Is it the case that the
   sl parm is ALWAYS RangeType for this fn?
**** Sorry - "sl parm"?  Please explain.

4.  Is the other parm for *vaLue*:ToCompute that you were speaking of
     -COMPUTE or something else?
**** Yes (to the disjunct), it was something else: IGNORE-CACHE.
So the call should be something like
(PROG ((u (GetValue un 'MyLivesInUnit '(SAFESLOT)))
       (s (GetValue un 'MyLivesInSlot '(SAFESLOT))))
   (RETURN (GetValue u s `(SAFESLOT (-CACHE (,u ,s)) (IGNORE-CACHE (,u ,s))))))

[which, unless the "s" slot is exceptional, is about the same as
	(UnitFnGV (GetValue un 'MyLivesInUnit '(SAFESLOT))
		  (GetValue un 'MyLivesInSlot '(SAFESLOT))
		  '(SAFESLOT)),
sorta]

The idea is to IGNORE the value stored in u:s -- that will be the
(*Do* FSeeUnit sOfu), which, if investigated, will lead to an infinite
recursion.  Note we don't want to store this computed value on u:s -- instead
it will be up to *vaLue*:ToCacheValue to decide what to do with this.
Maybe this function could meander about, and caching the value only if
s:ToCacheValue said to do so.  (ie something like
(LAMBDA (uN sL vAL ...) (* Note sL = *vaLue*, and uN is a subunit.)
	(APPLY* (GetValue (GetValue uN 'MyLivesInSlot) 'ToCacheValue)
		uN sL vAL ...))

5.  If each of the FnForVerifyingRangeRestriction fns takes only a pair
   of specs and the "loop" is done in RangeTypeOfTypicalSubUnit:VerifyAll,
   things seem to look simpler. See anything wrong with this?
**** I think not - but perhaps I'm just confused.  Could you spell out
your proposal.  (It sound like you think you're going to keep hitting
RangeTypeOfTypicalSubUnit:VerifyAll, which is NOT the case.)

6.  If I actually use the EqualFormatSpec approach instead of punting when
   there isn't a match, exactly what should be done?  The information
   that is encapsulated in the transformation function doesn't help
   in verifying that two specs are equivalent (at least to me).  I wouldn't
   necessarily think that you would want to actually do the transformation
   and see what results as a way of telling whether it is legal...
   Also not clear whether some mapping of the sub-specs needs to be done
   DEPENDENT upon the particular mapping at this un-equal level...
   Any enlightenment?

**** Depends on what you consider to be a legitimate subrange.  I, for example,
feel queasy at the prospect of letting something of format FSingleton be a
restriction of a FSet format -- but you indicated this is acceptable.
Possibility one: only include fmt2 on fmt1:EqualFormatSpec if it is a legal
restriction -- this makes the task trivial -- just use ASSOC.
If you want to include other formats, then you may have to do something like
include another field - indicating its acceptability as a restriction;
or possibly here's a place when your could use the FormatCharacter slot directly,
(avoiding this EqualFormatSpec altogether): by indicating which of the
characteristics must be the same, or how different.  Yes, 'twould be a bag of
worms, but might be worthwhile in the long run.
-------

Hi.  Any additions to the following list of fns to be recorded when
called from LISPX level?

   AddField  AddValue
   DeleteField
   KillField  KillValue
   PutField  PutValue
   SubstField  SubstValue
   UA-PUT
	**** Why this one?  (/\)
   UA-PUTPROP
	[remember to twiddle EDITU to use this \fn.]

I think I'll assume all changes are written to a single file and a filter
predicate will be applied at load time to pick the ones to be executed.  
	**** Yes, this makes sense.  
	How will you address the case of when a function breaks?
Otherwise there is no (reasonable) way to keep the sequencing straight
between the calls that would appear on several files.
-------

**** Russ

∂13-Jan-82  1912	Steve Klein <SKLEIN at USC-ISIB> 	recording changes    
To: RDG at SU-AI
∂26-Jan-82  2013	Steve Klein <SKLEIN at USC-ISIB> 	awoof 

Hi.  Typically, I got diverted onto other matters again.  Got your
example (TypicalShip stuff) through almost to completion, so I suppose
that about 95% of the "task" is done...should be easy to then test our
first example (the time units).  Several questions, of course, came up.
I should be back on track and have things "proved" near the end of the
week--get back to you then to go over the results, etc.  Enjoy.
-------

∂08-Feb-82  1617	Steve Klein <SKLEIN at USC-ISIB> 	grmmph

The bug where accessing a unit causes an end of file error has reappeared.
Since this is extremely irritating, I'm going to see if I can pin down what
is happening.  However, I need the CORLL sources to do so and can't find or
don't have access to them from RAND or SCORE...help.
-------

∂TO sklein@isib 15:51 9-Feb-82
A penny for...
Steve -
	Finally got a chance to write down my thoughts - for what they're worth.
Working thru this example, the top call was

Goal 1:
	GetValue(Ship#47 Cost),
(where Cost:Isa = AnyComplexSlot).

As no value was stored on the Cost slot of the Ship#47 unit, Cost:ToCompute
was called, which would compute this value. 

Goal 2:
	GetValue(Cost ToCompute)

had to be computed as well, which required ...
This ended up being inherited from TypicalComplexSlot:ToCompute, which,
if memory serves, basically calls

Goal 3:
	GetField(Ship#47 Cost ToCompute).

Not finding a CostOfShip#47 subunit, this calls 

	GetValue(ToCompute ToComputeField),

handing it Ship#47 and Cost.  
(Is this right?  I don't think its ToComputeField(Cost)...)
Anyway, that TC:TCF function is an OR junction of a MapUntilOk and a
GetValue.  

    Note in this case, we'd like the MapUntilOk to return NIL, letting
    the TC:TCF function return the value of 
    GetValue(Cost ToCompute) -- which is what should happen.
    (That is, the result of Goal 3 is Cost:ToCompute.)
    But back to the plot:

Let ops <= Ship#47:OrderedPrototypes.  The MapUntilOk takes each op-i IN ops,
and asks for (GetField op-i 'Cost 'ToCompute '(-CreateSubUnit...)).

	In our case, we'd like each such GetField to return an nonOK value,
	permitting the overall MapUntilOk to return NIL.

If there is no op-i:Cost subunit, Cost:ToComputeField is called, which does
the correct thing -- with the -CreateSubUnit value in the "other" arg, this 
will return NIL, as desired.

The problem is when there is such a subunit.  The first such case is for
CostOfTypicalShip.  Here  GetField(TypicalShip Cost ToCompute) reduces to
GetValue(CostOfTypicalShip ToCompute).  
This is appropriate -- if there was a value primitively stored, we'd want that
used.  Otherwise there may be a HighLevelDefn associated with CostOfTypicalShip,
from which we could compute that ToCompute value.

In this case, there is no primitive CostOfTypicalShip:ToCompute, nor is there
a CostOfTypicalShip:HighLevelDefn.  Now FunctionSpec:ToCompute (or maybe
the derived FunctionSpec:LispFn) tells us to check the 
Orderedprototypes of the unit (here CostOfTypicalShip),
seaching for a default value.
CostOfTypicalShip:Orderedprototypes includes TypicalSubUnit, and then
some even more irrelevant units -- TyppcalAbstractThing and TypicalThing.

Currently none of the three units has a ToCompute slot -- note that ToCompute
isn't even defined for the latter two units.

Some notes: (1) The GetAccessFn included in FunctionSpec:ToCompute
insists that a value be found here -- it gives the warning message now found.
(I think -- I'm not quite sure of this.)
(2) Part of me wants to make AnySubUnit a subclass of AnySlot -- in which class
the TypicalSlot:ToCompute value will be found, saving the day.  But the rest
of me conceeds that this would be a great step backwards... Sigh.

There are several things which could be done.

(i) Don't use GetAccessFn in FunctionSpec:ToCompute.
Use instead a related, but less complaining function -- one which tolerates
not finding a value.  Then the caching part of this FS:TC will have to
be a bit smarter.  (Given that this isN'T the suggestion I'm backing, I'll
not elaborate.)

(ii) Store some new constant on TypicalSubUnit:ToCompute, effectively meaning
stop looking, and return me.  (Proposed name: NothingHereOrAbove.)
This value will be returned by MapUntilOk.  Note we still want the OR
to ignore this answer, requiring a new predicate IsOk&Significant
(which is (LAMBDA (x) (AND (IsOk x) (NEQ x NothingHereOrAbove) x)).
This would go around the MapUntilOk.
Problems: should this value be cached on TypicalShip:ToCompute?
How should this be added to TypicalSubUnit -- given that it is not the function
which ToCompute:RangeType expects.  Should FSingleton, and friends, know about
this new constant?  Do we really need it?  ... what a mess ...

(iii) Perhaps the value of CostOfTypicalShip:ToCompute should be something like
(*Do* FSeeU&S Cost ToCompute)?  Working backwards, this may imply that
TypicalSubUnit:ToCompute be something like 
(*Do* FExecute (LAMBDA (u s o) (* Here u is, eg, CostOfTypicalShip)
		       `(*Do* FSeeU&S , (GetValue u 'MyLivesInSlot) ToCompute))).
This seems hacky -- especially when the time comes to cache this value of
CostOfTypicalShip:ToCompute.

(iv) and now for the real proposal:  Store something like
	(*Do* FExecute (LAMBDA (u s o) 
			       (GetValue (GetValue u 'MyLivesInSlot) 'ToCompute)))
This will compute, here, Cost:ToCompute.  This value may then be cached away --
depending on the function associated with Cost:ToCacheValue (which will probably
be whatever is found on TypicalComplexSlot:ToCacheValue).
NOTE: this eliminates the need for that top OR in TC:TCF, at least in this
case.
I recommend leaving the OR in, for now at least, as other things may use
this TC:TCF function (ie if this is the function stored on TypicalSlot:TCF).

----
Finally, realize the same types of things must be done for
RangeType and DomainType as they're computed with ToCompute.  (Ie this sort
of *DO* must be placed on those slots of TypicalSubUnit.)

----
Anyway, once this done, that Goal 3
[GetField(Ship#47 Cost ToCompute)] will return the correct value
[that is, the value of GetValue(Cost ToCompute)].
That will do the right thing -- satisfying Goal 2 and then Goal 1,
(i hope).

Sound good?

I'm not really happy about soln (iv) if it forces us to but something like
that messy *DO* clause on each slot on TypicalSubUnit.  Perhaps we could
circumvent that problem by talking about a particular class of slots, which
"terminate" on TypicalSubUnit with this sort of value...

Perhaps we should use that variable approach to cache some special value
on each TypicalXXX:YYY, whenever TypicalXXX is on YYY:MakesSenseFor -- to
shorten the othrwise duplicated long search.

More later.  Let me first mail this off, and await critiques.  Then we
can pursue patches to other RLL problems, and then, finally, address some of
these even more time-consuming issues.

Russ

By the way, Ben says Hi.
∂16-Feb-82  1415	Steve Klein <SKLEIN at USC-ISIB> 	postponement    

Hi.  Things have gotten hectic again...mind if I delay a continuation of our
conversation for a couple of days?
Steve.
-------

No problem.
∂TO skein@isib 18:01 17-Feb-82
Quicky
Steve
	I just realized I never had youse guys fill out a "non-disclosure
agreement" prior to using RLL.
So I'm now snail mailing a copy of that form, which I guess
you and Bill Mann should sign and send back.  (who knows why?)
	Russ